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Abstract

   This document specifies media type registrations for the RTP payload
   formats defined in the RTP Profile for Audio and Video Conferences.
   Some of these may also be used for transfer modes other than RTP.

Table of Contents
   1. Introduction ....................................................2
      1.1. IANA Considerations ........................................2
      1.2. Terminology ................................................3
   2. Registrations for "Audio/Video Profile" .........................3
      2.1. Audio Type Registrations ...................................3
      2.2. Video Type Registrations ..................................24
   3. Changes from RFC 3555 ..........................................25
   4. Security Considerations ........................................26
   5. References .....................................................27
      5.1. Normative References ......................................27
      5.2. Informative References ....................................27












Casner                      Standards Track                     [Page 1]

RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007


1.  Introduction

   This document updates the media type registrations initially
   specified in RFC 3555 for the Real-time Transport Protocol (RTP)
   payload formats defined in the RTP Profile for Audio and Video
   Conferences, RFC 3551 [1], as subtypes under the "audio" and "video"
   media types.  This document does not include media type registrations
   for the RTP payload formats that are referenced in RFC 3551 but
   defined in other RFCs.  The media type registrations for those
   payload formats are intended to be updated by including them in
   revisions of the individual RFCs defining the payload formats.

   The media type registrations specified here conform to the updated
   template format and procedures in RFC 4288 [2] and RFC 4855 [3].
   This update makes no technical changes in the registrations.
   Together with RFC 4855, this document obsoletes RFC 3555.

1.1.  IANA Considerations

   As a consequence of the generalized applicability of the media types
   registry as specified in RFC 4288, some changes in nomenclature are
   needed in the RTP Payload Format section of the registry.  In the
   registry title "RTP Payload Format MIME types" and the introductory
   text, "MIME" should be changed to "media". "MIME" should be deleted
   from the table headings, leaving just "media type" and "subtype".

   This document updates the media type registrations listed below to
   conform to the revised registration format specified in RFC 4288 and
   RFC 4855, so the reference for these media types should be changed
   from RFC 3555 to this document.  Some media type registrations
   contained in RFC 3555 are omitted from this document; the existing
   registrations for those types continue to be valid until updated by
   other RFCs.  There are no new registrations contained here.
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      audio/DVI4
      audio/G722
      audio/G723
      audio/G726-16
      audio/G726-24
      audio/G726-32
      audio/G726-40
      audio/G728
      audio/G729
      audio/G729D
      audio/G729E
      audio/GSM
      audio/GSM-EFR
      audio/L8
      audio/L16
      audio/LPC
      audio/PCMA
      audio/PCMU
      audio/VDVI
      video/nv

   Media type audio/L16 was initially registered via RFC 2586 for
   transports other than RTP.  That registration is incorporated here
   and augmented with additional information for RTP transport.

1.2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4] and
   indicate requirement levels for implementations compliant with this
   specification.

2.  Registrations for "Audio/Video Profile"

   In the following sections, the RTP payload formats defined in the RTP
   Profile for Audio and Video Conferences, RFC 3551 [1], are registered
   as media types.

2.1.  Audio Type Registrations

   For most audio payload formats, the RTP timestamp clock rate is equal
   to the sampling rate.  Some payload formats operate only at one fixed
   sampling rate, while others are adjustable.

   These audio formats also include the optional parameters "ptime" to
   specify the recommended length of time in milliseconds represented by
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   the media in a packet, and "maxptime" to specify the maximum amount
   of media that can be encapsulated in each packet, expressed as time
   in milliseconds.  The "ptime" and "maxptime" parameters are defined
   in the Session Description Protocol (SDP), RFC 4566 [5].

2.1.1.  Registration of Media Type audio/DVI4

   Type name: audio

   Subtype name: DVI4

   Required parameters:
        rate: The RTP timestamp clock rate, which is equal to the
        sampling rate.  The typical rate is 8000, but other rates may
        be specified.

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550 [6]).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner
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   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.2.  Registration of Media Type audio/G722

   Type name: audio

   Subtype name: G722

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.
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2.1.3.  Registration of Media Type audio/G723

   Type name: audio

   Subtype name: G723

   Required parameters: none

   Optional parameters:
        ptime, maxptime: see RFC 4566

        bitrate: the data rate in kb/s used or preferred for the audio
        bit stream, with permissible values 5.3 or 6.3.  If
        unspecified, the bitrate may change from frame to frame as
        indicated inband.

        annexa: indicates that Annex A, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.
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   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.4.  Registration of Media Type audio/G726-16

   Type name: audio

   Subtype name: G726-16

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner
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   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.5.  Registration of Media Type audio/G726-24

   Type name: audio

   Subtype name: G726-24

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.




Casner                      Standards Track                     [Page 8]

RFC 4856      RTP Payload Formats for Audio/Video Profile     March 2007


2.1.6.  Registration of Media Type audio/G726-32

   Type name: audio

   Subtype name: G726-32

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.
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2.1.7.  Registration of Media Type audio/G726-40

   Type name: audio

   Subtype name: G726-40

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.
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2.1.8.  Registration of Media Type audio/G728

   Type name: audio

   Subtype name: G728

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.
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2.1.9.  Registration of Media Type audio/G729

   Type name: audio

   Subtype name: G729

   Required parameters: none

   Optional parameters:
        ptime, maxptime: see RFC 4566

        annexb: indicates that Annex B, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner
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   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.10.  Registration of Media Type audio/G729D

   Type name: audio

   Subtype name: G729D

   Required parameters: none

   Optional parameters:
        ptime, maxptime: see RFC 4566

        annexb: indicates that Annex B, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.
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   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.11.  Registration of Media Type audio/G729E

   Type name: audio

   Subtype name: G729E

   Required parameters: none

   Optional parameters:
        ptime, maxptime: see RFC 4566

        annexb: indicates that Annex B, voice activity detection, is
        used or preferred.  Permissible values are "yes" and "no"
        (without the quotes); "yes" is implied if this parameter is
        omitted.

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON
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   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.12.  Registration of Media Type audio/GSM

   Type name: audio

   Subtype name: GSM

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.
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   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.13.  Registration of Media Type audio/GSM-EFR

   Type name: audio

   Subtype name: GSM-EFR

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner
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   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.14.  Registration of Media Type audio/L8

   Type name: audio

   Subtype name: L8

   Required parameters:
        rate: the RTP timestamp clock rate

   Optional parameters:
        channels: how many audio streams are interleaved -- defaults
        to 1; stereo would be 2, etc.  Interleaving takes place
        between individual one-byte samples.  The channel order is as
        specified in RFC 3551.

        ptime, maxptime: see RFC 4566

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.
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   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.15.  Registration of Media Type audio/L16

   Media type audio/L16 was initially registered via RFC 2586 [10] for
   transports other than RTP.  That registration is incorporated here
   and augmented with additional information for RTP transport.

   Type name: audio

   Subtype name: L16

   Required parameters:
        rate: number of samples per second -- For non-RTP transport,
        the permissible values for rate are 8000, 11025, 16000, 22050,
        24000, 32000, 44100, and 48000 samples per second.  For RTP
        transport, other values are permissible but the aforementioned
        values are RECOMMENDED.  For RTP, the rate parameter indicates
        the RTP timestamp clock rate, which is equal to the sample
        rate.

   Optional parameters:
        channels: how many audio streams are interleaved -- defaults
        to 1; stereo would be 2, etc.  Interleaving takes place
        between individual two-byte samples.  The channel order is as
        specified in RFC 3551 unless a channel-order parameter is also
        present.

        emphasis: analog preemphasis applied to the signal before
        quantization.  The only emphasis value defined here is
        emphasis=50-15 to indicate the 50/15 microsecond preemphasis
        used with Compact Discs.  This parameter MUST be omitted if no
        analog preemphasis was applied.  Note that this is a stream
        property parameter, not a receiver configuration parameter.
        Thus, if parameters are negotiated, it may not be possible for
        the sender to comply with a receiver request for a particular
        setting.

        channel-order: specifies the sample interleaving order for
        multiple-channel audio streams (see RFC 3190 [7], Section 7).
        Permissible values are DV.LRLsRs, DV.LRCS, DV.LRCWo,
        DV.LRLsRsC, DV.LRLsRsCS, DV.LmixRmixTWoQ1Q2,
        DV.LRCWoLsRsLmixRmix, DV.LRCWoLs1Rs1Ls2Rs2, DV.LRCWoLsRsLcRc.
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        For interoperation with DV video systems, only a subset of
        these channel combinations is specified for use with 20-bit
        linear encoding in the DV video specification [9]; those are
        DV.LRLsRs, DV.LRCS, DV.LmixRmixTWoQ1Q2.  This parameter MUST
        be omitted when the AIFF-C channel order convention (see RFC
        3551) is in use.

        For RTP, ptime: RECOMMENDED duration of each packet in
        milliseconds.

        For RTP, maxptime: maximum duration of each packet in
        milliseconds.

   Encoding considerations:
        Audio data is binary data, and must be encoded for non-binary
        transport; the Base64 encoding is suitable for Email.  Note
        that audio data does not compress easily using lossless
        compression.

   Security considerations:
        Audio/L16 data is believed to offer no security risks.  This
        media type does not carry active content.  The encoding is not
        compressed.  See Section 4 of RFC 4856.

   Interoperability considerations:
        This type is compatible with the encoding used in the WAV
        (Microsoft Windows RIFF) and Apple AIFF union types, and with
        the public domain "sox" and "rateconv" programs.

   Published specification:
        RFC 2586 for non-RTP transports, RFC 3551 for RTP

   Applications that use this media type:
        The public domain "sox" and "rateconv" programs accept this
        type.

   Additional information:
        Magic number(s): none
        File extension(s): WAV L16
        Macintosh file type code: AIFF

   Person to contact for further information:
        James Salsman <jps-L16@bovik.org>
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   Intended usage:
        Common

        It is expected that many audio and speech applications will
        use this type.  Already the most popular platforms provide
        this type with the rate=11025 parameter, referred to as "radio
        quality speech".

   Restrictions on usage:
        In addition to file-based transfer methods, this type is also
        defined for transfer via RTP (RFC 3550).

   Author:
        James Salsman for non-RTP transports.
        Stephen Casner for RTP transport.

   Change controller:
        James Salsman for non-RTP transports.
        For RTP transport, IETF Audio/Video Transport working group
        delegated from the IESG.

2.1.16.  Registration of Media Type audio/LPC

   Type name: audio

   Subtype name: LPC

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none
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   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.17.  Registration of Media Type audio/PCMA

   Type name: audio

   Subtype name: PCMA

   Required parameters:
        rate: The RTP timestamp clock rate, which is equal to the
        sampling rate.  The typical rate is 8000, but other rates may
        be specified.

   Optional parameters:
        channels: how many audio streams are interleaved -- defaults
        to 1; stereo would be 2, etc.  Interleaving takes place
        between individual one-byte samples.  The channel order is as
        specified in RFC 3551.

        ptime, maxptime: see RFC 4566

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551
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   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.18.  Registration of Media Type audio/PCMU

   Type name: audio

   Subtype name: PCMU

   Required parameters:
        rate: The RTP timestamp clock rate, which is equal to the
        sampling rate.  The typical rate is 8000, but other rates may
        be specified.

   Optional parameters:
        channels: how many audio streams are interleaved -- defaults
        to 1; stereo would be 2, etc.  Interleaving takes place
        between individual one-byte samples.  The channel order is as
        specified in RFC 3551.

        ptime, maxptime: see RFC 4566

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.
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   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.1.19.  Registration of Media Type audio/VDVI

   Type name: audio

   Subtype name: VDVI

   Required parameters: none

   Optional parameters: ptime, maxptime (see RFC 4566)

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.

   Interoperability considerations: none

   Published specification: RFC 3551
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   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

2.2.  Video Type Registrations

   For most video payload formats, including the one registered here,
   the RTP timestamp clock rate is always 90000 Hz, so the "rate"
   parameter is not applicable.  Likewise, the "channel" parameter is
   not used with video, while "ptime" and "maxptime" could be but
   typically are not.

2.2.1.  Registration of Media Type video/nv

   Type name: video

   Subtype name: nv

   Required parameters: none

   Optional parameters: none

   Encoding considerations:
        This media type is framed binary data (see Section 4.8 in RFC
        4288).

   Security considerations:
        This media type does not carry active content.  It does
        transfer compressed data.  See Section 4 of RFC 4856.
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   Interoperability considerations: none

   Published specification: RFC 3551

   Applications that use this media type:
        Audio and video streaming and conferencing tools.

   Additional information: none

   Person & email address to contact for further information:
        Stephen Casner <casner@acm.org>

   Intended usage: COMMON

   Restrictions on usage:
        This media type depends on RTP framing, and hence is only
        defined for transfer via RTP (RFC 3550).  Transfer within
        other framing protocols is not defined at this time.

   Author:
        Stephen Casner

   Change controller:
        IETF Audio/Video Transport working group delegated from the
        IESG.

3.  Changes from RFC 3555

   RFC 3555 is obsoleted by the combination of RFC 4855 [3] and this
   document.  RFC 4855 retains the specification of procedures and
   requirements from RFC 3555, while the media type registrations from
   RFC 3555 were extracted into this document.  The media type
   registrations for the RTP payload formats that are referenced in RFC
   3551 [1], but defined in other RFCs, have been elided from this
   document because those registrations are intended to be updated by
   including them in revisions of the individual RFCs defining the
   payload formats.

   The media type registrations in this document have been updated to
   conform to the revised media type registration procedures in RFC 4288
   [2] and RFC 4855.  Whereas RFC 3555 required the encoding
   considerations to specify transfer via RTP, that is now specified
   under restrictions on usage.  The encoding considerations now warn
   that these types are framed binary data.  The change controller is
   also now identified according to current conventions.  The optional
   parameter "channels" was clarified for audio subtypes L8, PCMA, and
   PCMU.  Finally, reference [9], which was missing from RFC 3555, has
   been corrected.
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4.  Security Considerations

   This memo specifies media type registrations for the transfer of
   several compressed audio and video data encodings via RTP, so
   implementations using these media types are subject to the security
   considerations discussed in the RTP specification [8].

   None of these media types carry "active content" that could impose
   malicious side-effects upon the receiver.  The content consists
   solely of compressed audio or video data to be decoded and presented
   as sound or images.  However, several audio and video encodings are
   perfect for hiding data using steganography.

   A potential denial-of-service threat exists for data encodings using
   compression techniques that have non-uniform receiver-end
   computational load.  The attacker can inject pathological datagrams
   into the stream, which are complex to decode and cause the receiver
   to be overloaded.  However, none of the encodings registered here has
   an expansion factor greater than about 20, and all are considered
   relatively simple by modern standards (some are implemented on
   handheld devices and most were implemented on general-purpose
   computers ten years ago).

   As with any IP-based protocol, in some circumstances a receiver may
   be overloaded simply by the receipt of too many packets, either
   desired or undesired.  Network-layer authentication MAY be used to
   discard packets from undesired sources, but the processing cost of
   the authentication itself may be too high.

   RTP may be sent via IP multicast, which provides no direct means for
   a sender to know all the receivers of the data sent and therefore no
   measure of privacy.  Rightly or not, users may be more sensitive to
   privacy concerns with audio and video communication than they have
   been with more traditional forms of network communication.
   Therefore, the use of security mechanisms with RTP to provide
   confidentiality and integrity of the data is important.  Because the
   data compression used with these media types is applied end-to-end,
   encryption may be performed after compression so there is no conflict
   between the two operations.
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